Condionally include dxl attribute file

SystemAdmin - Tue Feb 22 05:20:52 EST 2011

Hi Paul,

I have created a dxl attribute which contains the code shown above. For all our dxl attributes, we always use the #include rather than the code directly
e.g. dxl attribute

#include <AttrObjTESTINCLUDE.dxl>

to make updates easy, the code lies on a server. The problem is that certain users may
not have access to the server, so when they open a module with such an included dxl attribute
file, they'll get dxl ERRORS. That's why I wanted to test whether the file was accessible by
the user before executing

Cheers, Paul

SystemAdmin - Tue Feb 22 06:27:49 EST 2011
OK - I understand what you're trying to do now.

I had a go at creating a DXL attribute in a DOORS module and used your code -
I get the same errors.

I think what is happening here is that eval_ runs in it's own context - if my understanding is correct, this means that it will not refer to any of the other DOORS scripts, constants, variables, functions etc, so eval_ doesn't understand what obj and attrDXLName means because it doesn't have access to their declarations.

I'm not really sure how you you can make obj and attrDXLName work in eval_ - there must be a way around this - Louie, Mathias or others might have a solution.

Mathias Mamsch - Tue Feb 22 07:30:51 EST 2011

You can put a "disclaimer" in the eval_ code to make the variables visible in the eval context (Just like the DOORS client does anyway). Put this to your include file:
 

Object obj = obj__; string attrDXLName = aDXLName__
obj.attrDXLName = "EXISTS"

Hope this helps, regards, Mathias

Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS

SystemAdmin - Wed Feb 23 06:55:45 EST 2011
Thanks Mathias,

That's a neater way of doing it rather than passing in the params. Works perfectly.
How do come by such info ?

Best regards, Paul

SystemAdmin - Fri Feb 25 01:53:48 EST 2011
Hi,

The above works perfectly when there are just a few objects in a module. Unfortunately,
in the included dxl attribute we also have #includes, and hence when we use eval_()there
is a big performance hit when there are many objects. This was touched on in another
thread, explaining that the #includes will be loaded each time eval_() is called, but so solution seemed to be offered. Link: https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14455598&#14455598

Anybody any ideas how to speed it up ?

Thanks, Paul

Mathias Mamsch - Sat Feb 26 16:35:37 EST 2011
Hmm ... that could be hard to come by. It depends on the szenario. If I got this right, you want to check on your includes and prevent error messages from invalid DXL attributes in case that somebody without the right scripting environment launches the code. I think other possibilities would be better suited for that, e.g. installing a pre-open trigger that will do a "noError" and supress all those DXL errors you get when opening a module. You can even do that on database level to supress those (useless) errors for all users.

However if you really think about doing the eval_ check only once, you would probably need two DXL attributes. The first one contains the no-eval include files to make it calculate fast. The second one will be a module/object level DXL attribute, which will make the eval_ check for the module calculation, and then for object calculation, it will read that value back and only if the include check on module level was successful, then it will query the other DXL attribute for the value.

You could also use a global cache instead of two different attributes, where you store the values for the complete module on the first evaluation and then read the values from the cache for all other objects. This is quite a hard thing to do in DOORS.

Regards, Mathias